fix(backup): sanitize failure message + classify reason + meter (SLA observability) - #79

Incident: a customer received a "Backup failed" notification containing raw
pg_dump stderr — the internal host/IP (pg.instanode.dev / 152.42.154.144:5432)
and the per-tenant role name (usr_…). The message was also non-actionable: the
backup credential is platform-managed, so there's nothing the user can do. And
because markFailed emitted no metric, a clean failure slipped past both
existing backup alerts (backup-stale fires only after 36h; no-followup only on
STUCK rows) — a paid-tier durability/SLA breach with no prompt page.

Root cause of *that* failure: crypto.Decrypt fails CLOSED, and the error was
"password authentication failed" (not a decrypt error) — so the credential
decrypted fine but the live DB role rejected it (stored connection_url drifted
from the role's password). That per-resource drift needs an ops fix; this
change makes the *class* of failure safe, classified, and observable:

- markFailed now persists a SANITIZED, customer-safe summary to
  resource_backups.error_summary + the backup.failed audit (what the email and
  backup-health surface read). Raw stderr stays in the worker log only.
- Classify failures by reason (auth|decrypt|config|dump|upload) via
  backupFailReason(); auth = credential drift (won't self-heal, SLA-relevant,
  paged) vs transient dump/upload (retried next run).
- New metrics instant_customer_backup_failed_total{reason} +
  instant_customer_backup_succeeded_total for an alert + success-ratio tile
  (rule 25 — NR alert + Prom rule + dashboard tile land in the infra PR).

Retry semantics already correct: Work() returns nil after markFailed, so auth
failures aren't hammered.

Tests: table tests for backupFailReason (incl. the exact prod stderr) and an
anti-leak guard asserting the sanitized summary never contains the host/IP/
role/pg_dump/password tokens. make gate green; new funcs 100% covered.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Operator request (2026-06-03): cap retained successful backups at 5 per
resource. Adds runKeepLastNSweep — retires every status='ok' backup that is
NOT among the keepHealthyBackupsPerResource (=5) most-recent for its resource,
even if still within the tier's time-based retention window. Reuses
runRetentionSweep's retire mechanism (delete S3 object, soft-flag the row via
s3_key=NULL; error_summary='retained:count-cap' distinguishes it from the
time-based 'retained:expired'). Runs at the end of each backup tick alongside
the existing retention sweep; fail-soft per victim so one S3/DB blip never
blocks the rest.

Tests: retire-beyond-cap, within-cap no-op, query-error, scan-error,
delete-error (skips DB update), db-update-error (fails soft). New method 100%
covered. make gate green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>